Subject: Re^2:We need TRUE multiple assigns
From: [email-masked]
Date: Fri, 14 Jan 94 03:04:00 CET
Newsgroups: comp.sys.amiga.applications

On Mi 12.01.1994 at 00:20:00 wrote user [email-masked]
under the subject 'Re^1:We need TRUE multiple assigns':

PE> I'd really like to say that that should be configurable when you set
PE> up the multi assign.  It would be nice if you could nominate any of
PE> the directories in the multi assign as the one in which new files
PE> should be created.  But this could have unfortunate consequences when
PE> a file by that name already exists earlier in the multi assign than
PE> the place where new files are created.  In that case, you'd create a
PE> new file, but when you read it, you'd see the old file.  The new one
PE> would fall into a sort of black hole:  it would be there, but hidden
PE> by an older file.
PE>
PE> So I guess the multi assign needs to create new files the way it does
PE> now: in the first constituent directory.  This guarantees that the new
PE> file will be seen, meeting my goal that an assign should act just like
PE> a directory, to the extent possible.
PE>
PE> There is a problem here, though.  A program that loads a file into
PE> memory, makes some changes, and then writes the file back to disk,
PE> e.g. a text editor, may have some problems.  If it reads the file from
PE> the second directory in the assign, but writes it back into the first,
PE> then it has in effect moved the file from one directory to another.
PE> For example, if S: is assigned to bench:s and sys:s in that order, and
PE> you edit s:startup-sequence, many editors would write your
PE> startup-sequence to bench:s.  Of course, when your startup-sequence is
PE> read, your multi assign for S: isn't set up yet, so the new
PE> startup-sequence is not used.
PE>
PE> One solution to this would be for the multi assign to search the
PE> constituent directories for a file of the same name as the file to be
PE> created, and always write the file there.  This would give the correct
PE> behavior, but seems kind of kludgey to me.  Still, it might be the
PE> best solution, as it doesn't require programs to do anything special.
PE>
PE> It would help for the multi assign device/handler/file system to
PE> respond to a call to Parent() by returning a lock on the directory in
PE> which the file really lives.  This is probably what it ought to do
PE> anyway.  In this case, constructing the full name from the locked file
PE> would give its true name, and opening *this* file for writing will
PE> write the file in the right place.  I doubt many programs do this,
PE> though.  It's certainly not "the unix way."

Sorry for the long quoting, but you'll understand, when i say this:

There is real Multiple assign handler already: pathmanager taken from the
WShell- distribution.

It handels multiple assigns in an own device. If you read such a assign, you'll
get the first, visible file. Which is first depends of the entries in the
assign-statement. if you write to this assign, the file is created in the first
reachable directory. EXCEPT if the file allready exists in another directory.

So i have set up my S: as follows:

assign S: path:config:,OSX:script,sys:s

this means i write first in an directory called config: (another assign though),
which is handy for all the programs that still use S: for configs and not ENV:.
Then i have some Shell-Script-files in the chain and at last the original
s-directory.

When i edit my startup-sequence it is rewritten in sys:s, not in config: because
it pre-exists there. If i create a new file and save it to s: it actually gets
created in config:

I use this goody since several years, actually since the time when my used bought
copy of WShell 1.3 broke under 2.04 and 3.0. It still works well under the
highest OS.

-- The Answer V3.00